When a transmitting end transmits media objects in the form of data packets to a receiving end, for instance via the Internet or an IP based wireless network, some of the data packets may be lost on the way. It is therefore common practice to transmit in addition error correction data to the receiving end. The error correction data may enable the receiving end to restore lost data packets to a considerable extent.
For Multimedia Broadcast Multicast Services (MBMS) download services, for example, which distribute data packets via the Internet or an IP based wireless network, a Forward Error Correction (FEC) at the application layer is used according to the RMT internet draft draft-ietf-rmt-flute-08.txt: “FLUTE—File Delivery over Unidirectional Transport”, Jun. 5, 2004. By using a simple source-blocking algorithm, the source data can be conveniently arranged into equal length packets and the packets can be FEC encoded to produce parity packets. The size of the packet can be conveniently chosen to satisfy the underlying network requirement.
The packetization and FEC encoding process which is employed for MBMS download services is illustrated in FIG. 1. For the FEC encoding process, K data packets 13 of equal size S are formed from available data. Data symbols at the same position in each data packet 13 are used for generating (N-K) FEC symbols or parity symbols. Dotted lines in FIG. 1 represent a respective single codeword 19 consisting of K data symbols and (N-K) parity symbols. The codeword 19 can be for example a systematic RS codeword. The ith parity symbols in each codeword, with i=0 to (N-K), then form a respective parity packet 16, which are transmitted together along with the data packets 13.
At the receiving end, lost data packets 13 can then be recovered, if any K (1+ε) packets 13, 16 out of a total of N packets are received. Here, ε is known as the reception overhead or decoding inefficiency. For Reed-Solomon (RS) Codes, ε is equal to zero. This scheme of packetization will be referred to in the following as a “packet-based approach”.
According to the technical document 3GPP S4-040549: “Requirements on FEC Architecture and Codes for MBMS Streaming”, an FEC at the application layer is to be used as well for MBMS streaming. A FEC architecture for MBMS streaming shall include the packetization, interleaving, FEC encoding and FEC decoding procedures that meet these requirements.
For MBMS streaming services, however, the packet based approach described above for MBMS download services has severe disadvantages. For MBMS streaming services, the media objects are segmented into packets using the Realtime Transfer Protocol (RTP)/User Datagram Protocol (UDP)/Internet Protocol (IP), where the size of the RTP packets of the application layer is variable and highly media dependent. Padding bits could be employed to obtain equal size data packets from variable size RTP packets, but this could result in a significant wastage of FEC overhead. Alternatively, the media-encoders, like H.264 encoders, could be requested to provide almost equal-size RTP packets, but MBMS streaming services shall support a wide range of source-encoders, which may not all output equal-length RTP packets. Moreover, MBMS streaming shall support pre-encoded media streams also. Hence, it is necessary to use an approach which supports the use of an FEC with variable size RTP packets instead of equal length packets.
There exist several IETF frameworks that facilitate the use of an application layer FEC for streaming, but which do not meet the requirements of an FEC architecture for MBMS streaming.
The frameworks presented in the IETF document RFC 2733: “An RTP Payload Format for Generic Forward Error Correction”, December 1999, and in the Internet Draft IETF I-D ULP draft-ietf-avt-ulp-10.txt: “An RTP Payload Format for Generic FEC”, Jul. 18, 2004, both have the drawback that they are applicable only to simple XOR based FEC codes, while there exist much more powerful FEC codes, like Reed-Solomon codes, Low Density Parity Check (LDPC) codes, Raptor codes, etc., that have moderate or at least manageable complexity. Moreover, in the case of the RFC 2733, the FEC can be used to protect at the most 24 data packets, and in the case of the ULP draft, the FEC can be used to protect at the most 48 data packets. Thus the block length of the FEC is limited to 24 or 48 data packets, respectively. Reed-Solomon and LDPC codes, however, need larger block lengths that cannot be provided by the presented packetization frameworks. Moreover, both documents recommend the use of zero-padding in order to deal with variable size RTP packets. If the variation in the RTP packet length is high, this results in a significant amount of FEC being used to protect zero-padded bits. The ULP document moreover supports unequal error protection that may or may not be used at all for MBMS streaming.
The framework presented in the Internet Draft IETF I-D UXP draft-ietf-avt-uxp-06.txt: “An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams”, October 2003, has the drawback that it destroys the original RTP packet structure by interleaving. It is a requirement of the above cited specification S4-040549, however, to preserve the original RTP packets so that also receiving ends not supporting the FEC are able to obtain the original RTP packets. Moreover, this document is applicable to Reed-Solomon codes only, while there exist more powerful yet less complex FEC codes, like LDPC, Raptor etc. The UXP draft moreover supports as well unequal error protection that may or may not be used at all for MBMS streaming.
The Internet draft IETF I-D draft-luby-avt-rtp-generic-fec-00.txt: “RTP Payload Format for Generic FEC-Encoded Time-Sensitive Media”, Jul. 9, 2004, proposes as well to borrow the packet-based approach of the FLUTE architecture for streaming, for instance by including an FEC Payload Identity (ID) comprising a Source Block Number (SBN) and an Encoding Symbol ID (ESI) in the RTP payload. The SBN identifies a source block to which the RTP packet belongs. The ESI indicates an address or position of the first byte of the RTP packet in the matrix. But the document does not give any details of a packetization, interleaving, encoding and decoding of any particular FEC.
In order to address some of the difficulties mentioned above, in addition matrix-based approaches have been proposed for packetization of streaming data for FEC encoding, instead of the packet-based approach. For instance, in the ETSI document EN 301 192 c1.4.1 (2004-06): “Digital Video Broadcasting; DVB Specification for Data Broadcasting”, Reed-Solomon codes are specified to be used for an FEC at the link layer. The matrix-based approach is employed to efficiently deal with variable size IP datagrams in the packetization for the FEC.
Such a matrix-based approach is illustrated in FIG. 2, which presents the employed matrix structure.
A fixed size matrix comprises N=255 columns and a pre-specified number of rows. Each row comprises one byte per column. The first K=191 columns of the matrix are filled column by column with variable size IP datagrams 23 arranged back-to-back. The last column or columns, which can not be filled with an entire IP datagram anymore, are filled with padding data 25.
An RS (255,191) code is applied across each row of 191 data bytes to produce 64 parity bytes. Thus, each row of the matrix contains a systematic 255-byte long RS codeword 27 comprising 191 data bytes and 64 parity bytes 26. The IP datagrams 23 in the matrix are transmitted independently from each other, along with an additional field that indicates their address in the matrix. The parity bytes 26 are equally transmitted as IP datagrams along with their address in the matrix.
A receiving end can then form a corresponding matrix with whatever IP datagrams it had received by using the address of the datagrams in the matrix. A decoder associated to the receiving end then tries to restore the missing data bytes in the matrix by decoding each RS codeword. The RS decoders that are used for erasure correction are based on structured matrices like Vandermonde matrix or Cauchy matrix. The decoding involves (1) an inversion of a square matrix formed from a subset of the columns of Vandermonde matrix or Cauchy matrix. (2) Multiplication of the received codeword with the inverted matrix. Since each RS codeword is decoded independently, a matrix inversion and multiplication is required for each codeword. This could increase the decoding complexity when compared to the packet-based approach. In the packet-based approach, the positions of the lost bytes are the same in all rows. Thus, only one matrix inversion is needed for decoding all rows of the matrix.
In the technical documents 3GPP S4-040029: “Matrix approach vs. packet approach for MBMS application layer FEC”, Feb. 23-27, 2004, and 3GPP S4-030732: “Outer coding at the BM-SC for IP packet recovery in MBMS”, Nov. 24-28, 2003, it has been proposed to use a similar matrix-based approach employing RS codes at the application layer instead of at the link layer. In this case, the matrix of FIG. 2 would be filled with RTP packets instead of IP datagrams. Similar as the above mentioned document ETSI EN 301 192 c1.4.1, the documents S4-030732 and S4-040029 describe how to apply RS code independently across each row of this matrix.
In the technical document 3GPP S4-040526: “FEC architecture for MBMS Streaming Services”, Aug. 16-20, 2004, it has equally been proposed to use a matrix-based approach to support an FEC for MBMS streaming. It is suggested to include an ESI and an SBN in each RTP packet, and in addition the Source-Block Length (SBL) in each FEC RTP packet. However, it does not describe how data symbols are to be mapped into codewords. The document describes only a generic architecture which allows applying any type of FEC for MBMS streaming. Moreover, after an FEC decoding with the matrix-based approach, the Media RTP packets must be read out from the matrix for consumption, that is, for media decoding or playout. With the current set of fields defined in document S4-040526, it is not possible to recognize the boundaries of the Media RTP packets in the matrix, though.